The service called Push-to-Talk over Cellular (PoC) allows a user or sender to select one or more recipients and then, when he has pressed a special Push-to-Talk over Cellular key (PoC key), to transmit                speech        to a plurality of recipients simultaneously        using the half-duplex method, i.e. only the sender can speak and the recipients cannot interrupt him while he is speaking.        
With this service, the voice data are usually already being distributed over the telecommunication network while the sender is speaking. This is also called “streaming”. Thus, from the point of view of the user, Push-to-Talk over Cellular is similar to conventional CB radio, but with the extension that the sender is able to speak to recipients throughout the world who are able to be reached using the communications engineering of at least one telecommunication conference network, preferably a mobile radio telecommunication conference network. However, one prerequisite is that these recipients are also registered in the telecommunication network at the time at which the telecommunication link is set up, and in the case of a mobile radio communication network this means that they are registered, in other words that they are “online”.
Push-to-Talk over Cellular has been specified in a first version in an industrial consortium and is described in Push-to-Talk over Cellular (PoC); PoC Release 2.0. Further activities take place in the Open Mobile Alliance (OMA) and 3rd Generation Partnership Project (3GPP) standardization committee.
Push-to-Talk over Cellular is implemented in the “packet switched domain” (PS domain, i.e. in the packet-switched domain of the telecommunication network; the communication network protocol used on the network layer level is the Internet Protocol (IP)).
For every Push-to-Talk over Cellular group session there is a central Push-to-Talk over Cellular server device, known as the controlling PoC server. During a PoC group session, the PoC client devices are linked to the controlling PoC server via a respective “participating server” associated with them. By way of example, the signaling communication link between a PoC client and a participating PoC server or between a participating PoC server and a controlling PoC server uses the IP Multimedia Subsystem (IMS), which uses the “Session Initiation Protocol” (SIP) as signaling communication protocol, as described in RFC 3261 “SIP: Session Initiation Protocol”. The data transmission communication link between the PoC client and the participating PoC server or between the participating PoC server and the controlling PoC server uses the “Transport Protocol for Real Time Applications” (RTP).
Push-to-Talk currently has three different types of PoC groups (Push-to-Talk over Cellular groups), which are distinguished essentially by the structure of the PoC group session:
Ad-hoc PoC Group Session:                Before an ad-hoc PoC group session is set up, the initiator of the ad-hoc PoC group session defines a list of PoC users, including their address, for example their telephone number, as an SIP-URL (Session Initiation Protocol Unique Resource Locator) or an SIP address as an SIP-URL.        In this connection, it should be noted that the list of PoC users may also comprise just one person. The list is included in the dispatch from the initiating PoC client to the controlling PoC server when the ad-hoc PoC group session is set up, and the controlling PoC server then invites all the PoC users contained in the list to join the ad-hoc PoC group session. Invited PoC users may accept, turn down or else ignore this invitation.        
Prearranged PoC Group Session:                If one recurrently wishes to conduct a PoC group session with the same PoC users, a PoC user is able to define his own personal, fixed groups and to notify the controlling PoC of them. These are the “prearranged PoC groups”.        By way of example, a PoC user can define his own prearranged PoC group “friends” with the appropriate PoC users, including their address, for example a telephone number SIP-URL or an SIP address as an SIP-URL.        The prearranged PoC group is then allocated a dedicated group address, for example an SIP-URL. This group address is included in the dispatch from the initiating PoC client to the controlling PoC server when the prearranged PoC group session is set up, and the controlling PoC server then invites all the PoC users belonging to the prearranged PoC group to join this prearranged PoC group session. Invited PoC users may accept, turn down or else ignore this invitation.        
Chat PoC Group Session:                Chat PoC groups are likewise firmly defined, known to the controlling PoC server and relate, by way of example, to a particular topic of discussion. With this type of PoC group, there is generally provision for a PoC user who is authorized to do so to dial into a chat PoC group session himself and then to be able to conduct a PoC group session with the other PoC users who are likewise taking part in this chat PoC group session as PoC participants.        This group session thus works in a similar manner to the provision made in a “chat room” on the Internet.        
With Push-to-Talk over Cellular, there are thus two different options for a PoC user to be able to become a PoC participant in a PoC group session. Either he dials into a PoC group session (which is the usual way in the case of a chat PoC group session) or he accepts an invitation (which is the usual way in the case of an ad-hoc PoC group session or in the case of a prearranged PoC group session).
Internet Draft “A Session Initiation Protocol (SIP) Event Package for Conference State” discloses a “Session Status Notification” service, as a service feature (Feature) of Push-to-Talk over Cellular, which is used to inform a PoC user of the current status of the PoC group session. Such a status may include, by way of example, who is currently a PoC participant in the PoC group session. When a PoC user registers for such a service, he is thus aware at any time of how many and which PoC participants are currently taking part in a PoC group session. This optional service feature is implemented by the SIP extension SUBSCRIBE/NOTIFY, as described in RFC 3265 “Session Initiation Protocol (SIP)-Specific Event Notification”.
If a PoC user wishes to take part in a discussion in a particular chat PoC group session, this PoC user may wish to take part only under certain conditions. By way of example, the PoC user may wish to take part in this chat PoC group session only if at least three people are already taking part in it, since he is of the opinion that the discussion cannot be of interest otherwise.
To be able to guarantee that such a condition is observed, the PoC user might register for the afore-mentioned service feature “Session Status Notification” and constantly, i.e. continuously, observe the current status regarding the chat PoC session of interest.
As soon as he establishes from the Session Status Notification messages transmitted to him that the condition which he himself has set, that is to say in this example that at least three PoC participants are already taking part in the PoC group session of interest, is met he does himself enter the appropriate chat PoC group session.
A different scenario is conceivable with an ad-hoc PoC group session or with a prearranged PoC group session.
When the PoC user is invited to join such an ad-hoc PoC group session or a prearranged PoC group session, he might turn down the invitation at first because a condition which he has chosen and which he himself has set, for example that his boss should also already be taking part in this PoC group session, is not met. In that case, he subsequently observes the status of this PoC group session of interest, for example likewise by registering for the service feature “Session Status Notification”, and dials into this PoC group session too as soon as his boss is also taking part as a PoC participant in the PoC group session of interest.
One particular drawback of the two scenarios described above is that the PoC user himself must constantly observe the current status of a particular PoC group session and cannot request that he join a respective PoC group session which is of interest to him until the condition which he has set is met. Another drawback of the practices described above is that if the condition is never met then the user has wasted a large amount of time and energy in constantly observing the status of the corresponding PoC group session. It is also possible on the basis of the practices described above that, although the condition is met, the fact that the user has not noticed that the condition is met until at a late time, means that he does not join the PoC group session until later or even until too late, and hence might not obtain information of interest to him which is distributed or interchanged in the PoC group session.
RFC 3311 “The Session Initiation Protocol (SIP) UPDATE Method” describes an SIP message UPDATE and RFC 2976 “The SIP INFO Method” describes an SIP message INFO.
RFC 2327 “SDP: Session Description Protocol” discloses the “Session Description Protocol” (SDP).
RFRC 3428 “Session Initiation Protocol (SIP) Extension for Instant Messaging” describes the SIP message MESSAGE.
The problems described above also arise in other telecommunication conferences, for example a telecommunication conference system on the Internet, which has been described in J. Rosenberg, A framework for conferencing with the session initiation protocol, SIP Internet-Draft, IETF SIPPING working group: Draft-IETF-SIPPING-conferencing-framework-02, June, 2004, for example and is called “conferencing framework”. On the basis of this telecommunication conference system, the standardization committee 3GPP also specifies the service IMS Conferencing.
Besides a method for controlling the access rights to multimedia telecommunication conference resources (also called floor control) and setting up conference rules (also called conference policy) the telecommunication conference system described in J. Rosenberg, A framework for conferencing with the session initiation protocol, SIP Internet-Draft, IETF SIPPING working group: Draft-IETF-SIPPING-conferencing-framework-02, June, 2004, also provides Session Initiation Protocol (SIP)-based procedures, inter alia for setting up, managing, entering and leaving telecommunication conferences. This system also contains methods for notifying the conference participants (also called Conference Notification Service) about specific information and events relating to the telecommunication conference. One of these notification methods is the aforementioned “Session Status Notification”, for example. Within the telecommunication conference system, it is possible to interchange any types of media between the participants, and for this reason the telecommunication conference system is subsequently also referred to as a multimedia telecommunication conference system.
To define different rules, the multimedia telecommunication conference system described in J. Rosenberg, A framework for conferencing with the session initiation protocol, SIP Internet-Draft, IETF SIPPING working group: Draft-IETF-SIPPING-conferencing-framework-02, June, 2004, defines the “Conference Policy Control Protocol” (CPCP), as described in H. Khartabil et al., The Conference Policy Control Protocol (CPCP), XCON, Internet Draft, IETF XCON Working Group: Draft IETF-XCON-CPCP-XCAP-01, July 2004.
US 2003/0153339 A1 describes a method in which a user sends a server a list of participants with the request to provide a conference involving the participants specified by the list of participants. In this case, the server checks, in particular, whether a conference involving the participants is already in existence and, if appropriate, adds the user to the conference retrospectively.
US 2004/0205212 A1 describes a method for forwarding service-related information to a network user. In this case, a terminal belonging to the network user requests event packets, and the network user is then informed about service configurations, for example.
US 2004/0199580 A1 describes a system for managing a conference in which a client application is used to configure a conference, a server unit manages the conference settings and configures a conference unit, so that the conference unit provides the conference at the scheduled time.